United States Patent [19] 

Ganesan et al. 



US006055567A 
[ii] Patent Number: 
[45] Date of Patent: 



6,055,567 
Apr. 25,2000 



[54] DISTRIBUTED DATA ACCESSING 
TECHNIQUE 

[75] Inventors: Ravi Ganesan, Roswell; Mark Tbdd 
Harris, Alpharetta, both of Ga.; Hans 
Daniel Dreyer, Gahanna; Kathryn 
Randall Wolfe, Westerville, both of 
Ohio 

[73] Assignee: CheckFree Corporation, Norcross, Ga. 

[21] AppL No.: 09/017,169 
[22] Filed: Feb. 2, 1998 

[51] Int. CI. 7 G06F 13/00 

[52] U.S. CI 709/219 

[58] Field of Search 709/200, 201, 

709/203, 217, 218, 219; 705/26, 27, 35, 
37, 40, 42 

[56] References Cited 

U.S. PATENT DOCUMENTS 

4,277,837 7/1981 Stuckert 364/900 

4,319,336 3/1982 Anderson et al 364/900 

4,460,960 7/1984 Anderson et al 364/200 

5,025,373 6/1991 Keyser, Jr. et al 364/408 

5,220,501 6/1993 Lawlor et al 364/408 

5,231,571 7/1993 D'Agostino 364/408 

5,283,829 2/1994 Anderson 380/24 

5,287,270 2/1994 Hardy et al 364/408 

5,325,290 6/1994 Cauffman et al 364/401 

5,326,959 7/1994 Perazza 235/379 

5,336,870 8/1994 Hughes et al 235/379 

5,341,429 8/1994 Stringer et al 380/23 

5,347,632 9/1994 Filepp et al 395/200 

5,383,113 1/1995 Kight et al 364/401 

5,420,405 5/1995 Chasek 235/379 

5,465,206 11/1995 Hilt et al 364/406 



5,483,445 1/1996 Pickering 364/406 

5,594,910 1/1997 Filepp et al 395/800 

5,655,089 8/1997 Bucci 395/240 

5,699,528 12/1997 Hogan 395/240 

5,710,889 1/1998 Clark et al 395/244 

5,727,249 3/1998 Pollin 705/40 

5,815,665 9/1998 Teper et al 709/229 

5,884,288 3/1999 Chang et al 705/40 

5,903,721 5/1999 Sixtus 713/201 

5,903,732 5/1999 Reed et al 709/229 

5,943,656 8/1999 Crooks et al 705/30 

OTHER PUBLICATIONS 

"Utilities adopt Web bill payment plans", by Wallace, Bob, 
Computer World, U31, N34, P51(2), Aug. 25, 1997. 
"Pushing the envelope", by Rafter, Michelle, Los Angeles 
Times, vll7, n71, Mon ed, Col 3, pDl, Feb. 9, 1998. 

Primary Examiner — Moustafa M. Meky 
Attorney, Agent, or Firm — Lalos & Keegan 

[57] ABSTRACT 

A distributed data accessing technique is disclosed. The 
technique is realized by storing, at a first network station, 
information identifying data which is available al a second 
network station, the second network station being different 
than the first network station. A signal is generated at the first 
network station representing the information identifying the 
available data and linking information to the second network 
station. The signal is transmitted to a third network station, 
the third network station being different than the first and the 
second network stations. The transmitted linking informa- 
tion is operable at the third network station to establish a 
network link over which the identified available data is 
transmittable from the second network station to the third 
network station. 
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DISTRIBUTED DATA ACCESSING 
TECHNIQUE 

FIELD OF THE INVENTION 

The present invention relates generally to distributed data 
networks and, more particularly, to a distributed data access- 
ing technique. 

BACKGROUND OF THE INVENTION 

There are two prevalent models for electronic bill pre- 
sentment that are currently used in industry. The first is an 
aggregation model 10, which is shown in FIG. 1. In its 
simplest form, the aggregation model 10 includes a cus- 
tomer 12, an aggregator 14, and a plurality of billers 16. The 
customer 12 can be, for example, an individual person, a 
family, or a business. The aggregator 14 can be a financial 
institution (FI) such as, for example, a bank. Alternatively, 
the aggregator 14 can be a separate entity which acts of 
behalf of a sponsor 18, which can also be an FI such as a 
bank. Each biller 16 can be of any billing institution type 
such as, for example, a local telephone company, a local 
electric company, a retail outlet, or a national long distance 
telephone company. 

Each biller 16 provides customer-related invoice data to 
the aggregator 14. The aggregator 14 serves as an interme- 
diary between each biller 16 and the customer 12 by 
providing bill presentment directly to the customer 12, 
potentially on behalf of the sponsor 18. 

There are two variants of the aggregation model 10 
resulting from the ownership, or "branding", of the presen- 
tation experience and the communication channel between 
the aggregator 14 and the customer 12. In one variant, the 
aggregator 14 may offer aggregator-branding, thus totally 
owning both the presentation experience and the communi- 
cation channel between the aggregator 14 and the customer 
12. In the other variant, the aggregator 14 may offer sponsor- 
branding, thus staying "behind the scenes" in terms of the 
presentation experience and supporting the communication 
channel between the aggregator 14 and the customer 12 on 
behalf of the sponsor 18. 

The second prevalent model for electronic bill present- 
ment is a biller direct model 20, which is shown in FIG. 2. 
In its simplest form, the biller direct model 20 includes a 
customer 12 and at least one biller 16. In the biller direct 
model 20, each biller 16 retains the customer-related invoice 
data and the full relationship with the customer 12 (i.e., the 
presentation experience and the communication channel). 
The customer 12 may have software for providing a capa- 
bility similar to Web browser bookinarking so as to allow 
easy navigation between billers, and thus some level of 
virtual aggregation. However, there is no actual aggregation 
such as with the aggregator 14 of the aggregation model 10 
described above. 

The above-described models present a dichotomy 
between a sponsor-centric view and a biller-centric view of 
bill presentment. That is, the aggregation model 10 allows 
the aggregator 14 and/or the sponsor 18 to use customer- 
related invoice data, bill presentment, and the communica- 
tion channel between the aggregator 14 and the customer 12 
for cross-selling or other peripheral services. The biller 
direct model 20, on the other hand, insures that control of 
customer-related invoice data, bill presentment, and the 
communication channel between the biller 16 and the cus- 
tomer 12 remains with the biller 16. 

Also, neither of the above-described models adopt a truly 
customer-centric view. That is, neither of the above- 
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described models allow a customer 12 to interact directly 
with individual billers 16 while retaining the benefits of 
interacting with a single aggregator 14 such as, for example, 
the ability to retain a single authentication and log-in pro- 

5 cedure and a common bill presentation framework. Further, 
neither of the above-described models allow a customer 12 
to retain the benefits of interacting with a single aggregator 
14 while allowing the aggregator 14, billers 16, and sponsor 
18 to retain certain preferences such as, for example, the 

10 ability to retain control of customer-related data and a 
communication channel with each customer 12. 
Accordingly, it would be desirable to provide a distributed 
data accessing technique which addresses the above- 
mentioned shortcomings of the above-described models. 

15 

OBJECTS OF THE INVENTION 

One object of the present invention is to provide a 
distributed data accessing technique that allows a customer 
to interact directly with individual billers while retaining the 
benefits of interacting with a single aggregator. 

Another object of the present invention is to provide a 
distributed data accessing technique that allows a customer 
to retain the benefits of interacting with a single aggregator 
25 while allowing the aggregator, billers, and sponsor to retain 
control of customer-related data and a communication chan- 
nel with each customer. 

Another object of the present invention is to provide a 
distributed data accessing technique that allows complete 
30 flexibility as to who is offering bill presentment: billers only, 
aggregator only (possibly on behalf of one or more 
sponsors), or some combination of the above. 

Another object of the present invention is to provide a 
distributed data accessing technique that supports an end- 
35 to-end audit trail from the initial stages of bill presentment 
to the final stages of bill payment, which can serve a variety 
of purposes, including improved customer care. 

The above-stated objects, as well as other objects, 
features, and advantages, of the present invention will 
40 become readily apparent from the following detailed 
description which is to be read in conjunction with the 
appended drawings. 

SUMMARY OF THE INVENTION 

45 

According to the present invention, a distributed data 
accessing technique is provided. The technique can be 
realized by storing, at a first network station, information 
identifying data which is available at a second network 

50 station. The first network station can be, for example, an 
electronic payment and customer service entity. The second 
network station can be, for example, a billing entity such as 
a utility company. The information identifying the data that 
is available at the second network station can be, for 

55 example, information which indicates that a bill is available 
at the second network station. 

A signal is generated at the first network station. The 
signal represents the information identifying the available 
data and linking information to the second network station. 

60 The linking information can be, for example, a web site 
address along with some additional parameters. 

The signal is transmitted to a third network station. The 
third network station can be, for example, a user entity such 
as a personal computer. The transmitted linking information 

65 is operable at the third network station to establish a network 
link over which the identified available data is transmittable 
from the second network station to the third network station. 



03/12/2004, EAST Version: 1.4.1 



6,055,567 

3 4 

That is, the third network station can invoke the linking The identified available second data is typically stored at 

information so as to create, for example, a link to the web the fourth network station. However, as with the second 

site of a utility company. network station, the identified available second data can be 

The signal is typically generated in response to a request provided to the fourth network station by an entity located 

for data. Such a request can include an identification of a 5 outside of the network. Again, such an outside entity could 

user so that the user can be authenticated. The signal is then be, for example, a legacy billing system or an established 

generated after the user is authenticated. The request is billing aggregator. 

typically received from the third network station. The The first network station can receive a first notification 

request, as well as any other events that occur between the that the identified available first data was transmitted from 

various network stations, can be logged at the first network 10 the second network station to the third network station, and 

station. The logged events can then be accessed by an entity a second notification that the identified available second data 

located outside of the network such as, for example, a was transmitted from the fourth network station to the third 

centralized customer service center. network station. The identified available first data is prefer- 

The identified available data is typically stored at the ably transmitted from the second network station directly to 

second network stauon. However, the identified available 15 the third network station, and the identified available second 

data can be provided to the second network station by an data is preferably transmitted from the fourth network 

entity located outside of the network. Such an outside entity station directly to the third network station. Both the iden- 

could be, for example, a legacy hilling system or an estab- titled available first data and the identified available second 

lished billing aggregator. data can be transmitted to the third network station so as to 

The first network station can receive a notification that the 20 be displayed in a presentation format. The presentation 

identified available data was transmitted from the second format can be, for example, an internet web page or a frame 

network station to the third network station. The identified of an mtemet web P a S e - 11 should be noted that the identified 

available data is preferably transmitted from the second available first data and the identified available second data 

network station directly to the third network station over the can be P^ented in separate frames of an internet web page 

network link. The identified available data can be transmit- 25 at the time - 

ted from the second network station to the third network BRIEF DESCRIPTION OF THE DRAWINGS 
station so as to be displayed in a presentation format. The 

presentation format can be, for example, an internet web In order to facilitate a fuller understanding of the present 

page or a frame of an internet web page. invention, reference is now made to the appended drawings. 

In accordance with a further aspect of the invention, the 30 drawings should not be construed as limiting the 

identified available data can be identified available first data, P rcsent invention, but are intended to be exemplary only, 

the linking information can be first linking information, the FIG- 1 is an aggregation model for electronic bill pre- 

network link can be a first network link, and further infor- sentment. 

mation identifying second data which is available at a fourth 35 FIG. 2 is a biller direct model for electronic bill present- 
network station can be stored at the first network station. ment. 

Similar to the second network station, the fourth network FIG. 3 is an infrastructure diagram of a distributed data- 
station can be, for example, a billing entity such as a retailer. base entity in accordance with the present invention. 
The information identifying the second data that is available pj^ 4 is a schematic diagram of an electronic bill 
at the fourth network station can be, for example, informa- 4Q presentment and payment system in accordance with the 
tion which indicates that a bill is available at the fourth present invention. 

network station. Pjq 5 ^ a schematic diagram of an electronic payment 

The signal that is generated at the first network station can and cust0 mer service (EPCS) entity in accordance with the 

further represent the further information identifying the present invention. 

available second data and second linking information to the 45 nG( 6 ^ a schematic diagram of the electronic bill 

fourth network station. As with the first linking information, resentment and payment system shown io FIG. 4, extended 

me second linking information can also be, for example, a tQ mdude aSBodated ^ecUy related systems . 

website address. , FIG. 7 is a schematic diagram of the electronic bill 

Hie signal can again be transmitted to the third network presentment and payment system shown in FIG. 4, extended 

stauon and the transmitted second linking ^formation is 50 t0 mclude certain mdirec dy related systems, 

operable at the thud networ :statio* 1 to FIG. 8 is a schematic diagram of the electronic bill 

network link over which the identified available second data & , . CTn A .* A 

is transmittable from the fourth network station to the third P^f^t and payment system shown in FIG 4, extended 

i * ** tv *u- j *. i * *• *u to mclude certain associated customer care entities, 

network station. The third network station can therefore . 

invoke the second linking information so as to create, for 55 FIG. 9 is a schematic diagram of the electronic bill 

example, a link to the web site of the retailer. presentment and payment system shown m FIG. 4, extended 

T^e signal can again be generated in response to a request 10 mclude a <*°tralized customer care entity . 

for data. The request can include an identification of a user FIG. 10 is a flowchart diagram showing initial sign-on 

so that the user can be authenticated for use with more than data and message flows between a user entity and a banking 

one network station. That is, only a single authentication 60 entity in the electronic bill presentment and payment system 

procedure is required for use with both the second and the shown in FIG. 4. 

fourth network stations. As before, the request, as well as FIG. 11 is a flowchart diagram showing sign-on and 

any other events that occur between the various network authentication data and message flows between a user entity, 

stations can be logged at the first network station. The a banking entity, and an EPCS entity in the electronic bill 

logged events can then be accessed by an entity located 65 presentment and payment system shown in FIG. 4. 

outside of the network such as, for example, a centralized FIG. 12 is a flowchart diagram showing bill availability 

customer service center. data and message flows between a user entity, a banking 
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entity, and an EPCS entity in the electronic bill presentment other distributed database entities, or other system compo- 

and payment system shown in FIG. 4. nents having an internal message interface. For example, in 

FIG. 13A is a flowchart diagram showing billing entity ■ bill presentment and payment system, communication 

presentment data and message flows between a user entity, between a banking entity and a billing entity may be 

a billing entity, and an EPCS entity in the electronic bill 5 required. The external message interface 36 defines mes- 

presentment and payment system shown in FIG. 4. ™ "5* * ^mumcate and query data between 

F . ... the given distributed database entity 30 and any existing 

FIG. 13B is a flowchart diagram showing billing aggre- S ystem(s) that are directly related to the given distributed 

gator bill presentment data and message flows between a database entity 30. For example, an FI such as a bank can 

user entity, a billing entity, an EPCS entity, and an estab- have an existing direct deposit account (DDA) system. The 

lished billing aggregator in the electronic bill presentment partner message interface 38 defines messages that are used 

and payment system shown in FIG. 4. to communicate and query data between the given distrib- 

FIG. 13C is a flowchart diagram showing alternative uted database entity 30 and any existing system(s) that are 

system bill presentment data and message flows between a indirectly related to the given distributed database entity 30. 

user entity, an EPCS entity, and an alternative bill present- 15 For example, in a bill presentment and payment system, 

ment and payment system in the electronic bill presentment communication with an established billing aggregator may 

and payment system shown in FIG. 4. be necessary to satisfy customer demands. The customer 

FIG. 14 is a flowchart diagram showing bill payment data care message interface 40 defines messages that are used to 

and message flows between a user entity, an EPCS entity, communicate and query data between the given distributed 

and a billing entity in the electronic bill presentment and 20 database entity 30 and a customer care entity. For example, 

payment system shown in FIG. 4. in a biU presentment and payment system, a billing entity 

FIG. 15 is a flowchart diagram showing bill remittance may allow a third party to access biU data in order to provide 

and debiting data and message flows between an EPCS f f ^ t0 bjU customers. It should be noted that all of the 

entity and a billing entity and a banking entity in the above-described interfaces wiU be described in greater detail 

electronic bill presentment and payment system shown in 25 e ow ' 

PIG 4 Referring to FIG. 4, there is shown a schematic diagram 

FIG. 16 shows an example of a branded interface having of a ^ reatile C Jf Ctron ^ P reseQtment and W™" 

* ~„ f t L f • i,,^ „ fioM tem 50 in accordance with the present invention. The system 

a sign-on request prompt that includes a username neld and _ A . r , . . '. u . 

a password field 50 ^P^s a ^ eDtltv 52 ' a banking entity 54, a billing 

„ _ , * • . ™ entity 56, and an electronic payment and customer service 

FIG. 17 shows an example of a banking entity home page, (EPC S) entity 58. For purposes of this detailed description, 

including a view bills icon, a view checking account the user enuty 52, me bankmg entity 54, me billing entity 56, 

icon, and a view savings account icon. and the EPCS entity 58 are each distributed database entities 

FIG. 18 shows a first modified banking entity home page 30 as defined above. Thus, the user entity 52, the banking 

having a frame presenting new bill availability data. ^ ent i ty 54^ me billing entity 56, and the EPCS entity 58 each 

FIG. 19 shows a second modified banking entity home has a database component 32, an internal message interface 

page having a frame presenting detailed bill data. 34, an external message interface 36, a partner message 

FIG. 20 is a flowchart diagram showing customer service interface 38, and a customer care message interface 40. It 

data and message flows between a centralized customer should be noted, however, that the user entity 52, the 

service center, and an EPCS entity, a billing entity, and a 40 banking entity 54, the billing entity 56, and the EPCS entity 

banking entity in the electronic bill presentment and pay- 58 are not required to have a database component 32, an 

ment system shown in FIG. 4. internal message interface 34, an external message interface 

36, a partner message interface 38, and a customer care 

DETAILED DESCRIPTION OF A PREFERRED message interface 40. That is, the user entity 52, the banking 

EMBODIMENT ^ em j t y 54, the billing entity 56, and the EPCS entity 58 are 

Referring to FIG. 3, there is shown an infrastructure onl y required to have an internal message interface 34 so 

diagram of a distributed database entity 30 in accordance that communications can take place between each entity, 

with the present invention. The distributed database entity At this point it should be noted that, although only a single 

30 comprises a database component 32 and a plurality of user entity 52, banking entity 54, billing entity 56, and EPCS 

message interfaces 34-40 for facilitating communication 50 entity 58 is shown in the system 50, it is common to have a 

between the database component 32 and other distributed plurality of such entities in an actual versatile electronic bill 

database entities and system components. The database presentment and payment system in accordance with the 

component 32 typically contains data that is controlled or present invention. 

"owned" by the controller or "owner" of the distributed As previously described, an internal message interface 34 

database entity 30. For example, if the distributed database 55 defines messages that are used to communicate and query 

entity 30 is owned by a financial institution (FI) such as a data between distributed database entities. Thus, since the 

bank, then the database component 32 could contain infor- user entity 52, the banking entity 54, the billing entity 56, 

mation such as checking and savings account balances. It and the EPCS entity 58 are all distributed database entities, 

should be noted, however, that the database component 32 they all communicate through internal message interfaces 

can also contain data from other distributed database entities 60 34. The communications are performed over interconnec- 

and system components, as will be described in detail below. tions 60, which can be electrical wire, optical fiber, or 

The plurality of message interfaces 34-40 includes an microwave-based interconnections, 

internal message interface 34, an external message interface At this point it should be noted that each internal message 

36, a partner message interface 38, and a customer care interface 34, as well as each external message interface 36, 

message interface 40. The internal message interface 34 65 partner message interface 38, and customer care message 

defines messages that are used to communicate and query interface 40, can be implemented using any number of 

data between the given distributed database entity 30 and existing message-based communication systems such as, for 
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example, a TCP/IP message-based communication system This view is held primarily due to the trust that consumers 

running on the infrastructure of the internet. Alternatively, typically place in a bank brand, and the fact that bank 

the internal message interfaces 34, the external message customers who already bank online are also likely to want to 

interfaces 36, the partner message interfaces 38, and the receive bills online. Thus, in the following discussion, the 

customer care message interfaces 40 could be implemented 5 banking entity 54 is assumed to be the aggregator of the 

with proprietary messaging software on a private network or system 50. It should be noted, however, that any one of the 

intranet. It should also be noted that there are no require- other entities could also be the aggregator of the system 50 

ments as to the nature of the messaging protocol, or any in accordance with the present invention. There are several 

middleware used to support the messaging. factors which can be used to determine aggregator status 

The user entity 52 is typically a personal computer (PC) 10 sucn as > for example, market clout, 

that is directly connected to the system 50, or is connected The banking entity 54 typically gains access to the system 

to the system 50 through a network server. Thus, the 50 through a network server. Thus, the database component 

database component 32 associated with the user entity 52 32 associated with the banking entity 54 can be located in 

can be located on the PC (e.g., a traditional "fat" client), or the network server. It should be noted that the database 

on the network server (e.g., an HTML browser client). It 15 component 32 associated with the banking entity 54 can also 

should be noted that the database component 32 associated be located in a system associated with the banking entity 54 

with the user entity 52 can also be located in one of the other such as, for example, a DDA system. Such a DDA system 

distributed database entities, which can download data to the could be accessed through the external message interface 36 

user entity 52 (e.g., a Java client). It should also be noted that of the banking entity 54, as described in detail below. It 

the database component 32 associated with the user entity 52 20 should further be noted that the database component 32 

can be distributed among all three of the above-listed associated with the banking entity 54 can also be located in 

locations, owing to the distributed nature of each database one of the other distributed database entities, or be distrib- 

component 32. Thus, each database component 32 should uted among many of the above-mentioned locations, owing 

not be thought of as a single, monolithic database. Rather, to the distributed nature of each database component 32. 

each database component 32 is better described as a distrib- 25 wherever it is located, the database component 32 asso- 

uted repository of data categorized by the entity that "owns" c i atec j w i tn tne banking entity 54 stores bank-specific sub- 

me data, scriber profile data profile such as, for example, subscriber 

Wherever it is located, the database component 32 asso- names and addresses and subscriber account numbers. The 
ciated with the user entity 52 stores data that is related to the database component 32 associated with the banking entity 
type of user interface (UI) that is being presented to a 30 54 can also store account information such as, for example, 
subscriber of the system 50. For example, the database static account information (e.g., lease rate, principle), and 
component 32 associated with the user entity 52 can store dynamic account information (e.g., balance). The database 
data that is related to the particular type of presentation component 32 associated with the banking entity 54 can 
technology being used (e.g., a "fat" client, an HTML further store profile data specifically associated with the FI 
browser client, or a Java client), a specific application, or a 35 such as, for example, graphics, business rules, banking- 
particular version. The database component 32 associated related transaction histories, and aggregation relationships 
with the user entity 52 can also store data that is related to such as those between the FI and billers. 
a particular computing session such as, for example, the Since it is likely that the system 50 will be used with 
existence of a computing session and/or the duration of a existing banking systems such as, for example, an existing 
computing session. The database component 32 associated DDA system, one of the main functions of the banking entity 
with the user entity 52 can further store subscriber authen- 54 ^ the continuation of current banking and bill payment 
tication data, which is described in detail below. functionality including the maintaining of customer profiles 

The main function of the user entity 52 is to build a UI and already existing interfaces. In its role as aggregator, the 

using data obtained from the other distributed database 45 banking entity 54 also provides data to the user entity 52 to 

entities, and then present the UI to a subscriber of the system be used for the creation of a navigation portion of a UI. For 

50. The presentation of the UI to a subscriber is dependent an HTML browser client, this data would be used to create 

upon the particular type of presentation technology being a navigation frame, but not a content specific frame. It 

used (e.g., a "fat" client, an HTML browser client, or a Java should be noted that the banking entity 54 can also provide 

client). For example, a UI for a Java client requires that 5Q data to the user entity 52 to be used for the creation of a UI 

presentation data be downloaded from one of the other for traditional banking and bill payment, 

distributed database entities. Since the banking entity 54 is generally viewed as the 

Other functions of the user entity 52 include storing primary point of presence for a subscriber to the system 50, 

certain data locally so as to facilitate off-line editing and the banking entity 54 also functions as the likely, but not 

viewing, maintaining a state in a connectionless environ- 55 exclusive, entry point for subscriber sign -on. Thus, the 

ment (e.g., an HTTP environment), and sensing the avail- banking entity 54 typically controls the sign-on and authen- 

ability of software updates and managing their subsequent tication procedures for subscribers through the user entity 

application. All of these functions depend on the nature of 52. It should be noted that the banking entity 54 typically 

the client (e.g., a "fat" client, an HTML browser client, or a works in conjunction with the EPCS entity 58 in controlling 

Java client). As previously indicated, another function of the 60 Ike authentication procedure, as described in detail below, 

user entity 52 includes storing subscriber authentication data Another function of the banking entity 54 includes track- 

(e.g., a security ticket) that is used to gain access to other ing bank related events and storing them in an event tracking 

distributed database entities in the system 50. database, which is typically associated with the EPCS entity 

The banking entity 54, which is typically an FI such as, 58, as also described in detail below, 

for example, a bank, is generally viewed as a primary point 65 The billing entity 56 is typically a biller such as, for 

of presence for a subscriber to the system 50, typically example, a utility company. The billing entity 56 typically 

providing an appearance of aggregation to the subscriber. gains access to the system 50 through a network server. 
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Thus, the database component 32 associated with the billing Wherever it is located, the database component 32 asso- 

entity 56 can be located in the network server. It should be ciated with the EPCS entity 58 stores bill payment-specific 

noted that the database component 32 associated with the subscriber profile data such as, for example, subscriber 

billing entity 56 can also be located in a system associated names and addresses, subscriber DDA account numbers, and 

with the billing entity 56 such as, for example, a legacy 5 subscriber credit ratings. The database component 32 asso- 

billing system. Such a legacy billing system could be ciated with the EPCS entity 58 also stores bill payment 

accessed through the external message interface 36 of the warehouse data such as, for example, user-specific payees, 

billing entity 56, as described in detail below. It should single occurrence payments, and recurring payments/ 

further be noted that the database component 32 associated models. 

with the billing entity 56 can also be located in one of the 10 As previously described, both the banking entity 54 and 

other distributed database entities, or be distributed among tne billing entity 56 track and store events in an event 

many of the above-mentioned locations, owing to the dis- tracking database. This event tracking database is typically 

tributed nature of each database component 32. located in the database component 32 associated with the 

Wherever it is located, the database component 32 asso- EPCS entity 58. The event tracking data that is stored 

ciated with the billing entity 56 stores biller-specific sub- 15 typically comprises event summaries and links to other 

scriber profile data such as, for example, subscriber names databases, perhaps residing at other entities, which provide 

and addresses and subscriber account numbers and types event details and/or an audit trail. 

(e.g., business vs. residential phone line). The database xhe database component 32 associated with the EPCS 

component 32 associated with the billing entity 56 also ent i tv 58 also stores bill payment transaction histories, and 

stores billing data for use by the user entity 52 in building 20 system subscriber profile data such as, for example, meta- 

the UI for the subscriber. The billing data can include bill data about subscribers and metadata about subscribers' 

availability data, detailed billing data, ads and other cross- relationships to other entities (e.g., a list of biilers that a 

sale displays and links, and bill payment terms and condi- subscriber has enabled). The database component 32 asso- 

uons - ciated with the EPCS entity 58 further stores billing-related 

The database component 32 associated with the billing 25 profile information on the system aggregator and biilers such 

entity 56 can also store biller transaction history such as, for as, for example, metadata about billing arrangements (e.g., 

example, bill data manipulation (e.g., viewing, searching, flat rate, per subscriber, event-driven, etc.), and aggregation 

sorting), and cross-sell events. The database component 32 data such as, for example, new bill availability and messages 

associated with the billing entity 56 can further store biller or special announcements available from the billing entity 

profile data such as, for example, graphics, business rules, 30 56. The database component 32 associated with the EPCS 

and relationships with aggregators such as banks. entity 58 still further stores security data such as, for 

The main function of the billing entity 56 is to provide example, required sign-on information and macro-level 

billing data to the user entity 52 for use in creating the UI for authorizations. The database component 32 associated with 

the subscriber. The billing entity 56 also provides bill 35 the EPCS entity 58 additionally stores customer service data 

availability data to an aggregator database, whether it is such as, for example, FAQ's, FI and biller contact 

located in the banking entity 54, the EPCS entity 58, or information, and problem resolution data, 

another entity, to provide notice of bill availability to sub- The EPCS entity 58 is the glue that holds the distributed 

scribers. The billing entity 56 can also access legacy billing database entities together. The EPCS entity 58 accomplishes 

systems through the external message interface 36 of the 4Q this by functioning as an integration agent by maintaining 

billing entity 56, as indicated above. bill payment profiles and warehouse data, aggregating bill 

Another function of the billing entity 56 includes tracking availability and status data (but not bill content or 

biller-related events and storing them in an event tracking presentation), and maintaining an event tracking database 

database, which is typically associated with the EPCS entity (or audit trail) that can be accessed by all of the database 

58, as described in detail below. 45 entities. Also, in order to facilitate a single point of sign-on, 

The EPCS entity 58 can generally be described in terms the EPCS entitv 58 functions as the authentication gate 

of a data processing system 70, such as shown in FIG. 5. The keeper. This doesn't mean to imply that the EPCS entity 58 

data processing system 70 preferably comprises at least one necessarily maintains user identification numbers and/or 

processor (P) 72, memory (M) 74, and input/output (I/O) passwords. However, it does imply that the EPCS entity 58 

interface 76, which are connected to each other by a bus 78, 50 acce P ts si ^-° n re <l ue sts and doles out authentication "tick- 

for implementing the functions of the EPCS entity 58, as ets " m response, in conjunction with the banking entity as 

described in detail below. described above. 

Referring again to FIG. 4, the EPCS entity 58 typically h should be noted that > like ^ identification numbers 

gains access to the system 50 through a network server. and passwords, other data elements, like event details, may 

Thus, the database component 32 associated with the EPCS 55 end U P bein g virtually aggregated by the EPCS entity 58, but 

entity 58 can be located in the network server. It should be ma y slin physically reside in a distributed manner across 

noted that the database component 32 associated with the several of the database entities. 

EPCS entity 58 can also be located in a system associated It should also be noted that the EPCS entity 58 may also 

with the EPCS entity 58 such as, for example, a legacy route e-mail messages to and from the various database 

aggregating system. Such a legacy aggregating system could 60 entities, as well as store e-mail messages sent to and from the 

be accessed through the external message interface 36 of the various database entities. 

EPCS entity 58, as described in detail below. It should As previously described, an internal message interface 34 

further be noted that the database component 32 associated defines messages that are used to communicate and query 

with the EPCS entity 58 can also be located in one of the data between distributed database entities. As also previ- 

other distributed database entities, or be distributed among 65 ously described, each internal message interface 34 can be 

many of the above-mentioned locations, owing to the dis- implemented using any number of existing message-based 

tributed nature of each database component 32. communication systems, or with proprietary messaging soft- 
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ware on a private network or intranet. Furthermore, the biller, bill payment, banking, etc.), sign-on data, bill avail - 

message specification or file format can be either standard ability data, bill viewed data, bill payment generated data 

(i.e., open) or proprietary. With this mind, the following (optionally associated with presented bill data), subsequent 

types of messages are examples of messages which may be bill payment events data (e.g., submitted, processed, failed, 

employed to implement an internal message interface 34 in 5 cleared, remittance received by biller, etc.), cross-sell events 

accordance with the present invention. data ( e g ( aG 7 0 ff e r viewed, ad/offer clicked, product/service 

Depending upon the nature of the presentation technology purchased), terms & conditions viewed data, e-mail created/ 

being used (e.g., a "fat" client, an HTML browser client, or read/deleted data 

a Java client), the user entity 52 may need to process an -r^ EPC s entity 58 will also process an internal messages 

internal message to store a security ticket for ater use in 10 related fi , e ^ such for fc * to 

gaining acoess to other _dis£buted daubase entities m the add/modify/delete/rea 5 subscriber file data> ofte £ ^ a 

system 50. Tht user entity 52 may also need to process an » f ^ ^ ^ ( emol]mftMt 

uiternal message to update any resident software. The user activation etc ) 

entity 52 may further need to process an internal message a 1V 1 * *'* . 

containing various types of information (assuming a push ^ ^ EPCS entlt y 58 wlU also P rocess internal security 

model). The user entity 52 may additionally need to process messages. Such internal security messages may relate to 

internal e-mail messages such as, for example, those for authentication, which result in the EPCS entity 58 issuing a 

receiving data from other database entities. security ticket. It should be noted that an authentication 

The banking entity 54 will process an internal message to ^ st f oes u not have *° ^ " a r ? suI [ of a s ^ber 

add/update/delete/retrieve FI branding information, as well 20 . to the network server of the banking entity 54. It 

as an internal message to add/update/delete an entry from a be mitia * d lf * ^ubsenber tries to gain access to the 

list of billers that have been aggregated. The banking entity bdhn S entl £ 5 «> and not even contactmg the bank- 

54 will also process an internal message to activate a m f en !^ 54 ^ pomt bemg that with a security ticket a 

subscriber for home banking via a messaging protocol, subscriber is generally allowed to freely traverse any data- 

which can be an existing messaging protocol such as, for 25 base entltv m * e s y stem 50 wlthout S om S throu * re P eated 

example, OFX or a batch process. The banking entity 54 will procedures. 

further process an internal message to query/update bank An internal security message may also relate to macro- 
subscriber profile data for purposes of customer care. The level authorization, wherein a security ticket may contain 
banking entity 54 will still further process an internal me credentials to allow a subscriber access to a particular 
message to query bank transaction history for customer care 30 billing entity, but doesn't address micro-level authorization 
and for linking to the event tracking database. The banking te^es such as allowed operations. 

entity 54 will still further process an internal message to An internal security message may also relate to getting a 

retrieve a list of billers available under the FI sponsor security ticket without authentication. Such a message will 

umbrella. An alternative to this is to place the list of billers originate from a trusted party (e.g., an FI performing its own 

available under the FI sponsor umbrella in an aggregation 35 authentication). Therefore, a security ticket is provided 

database. However, placing the list of billers available under without performing an authentication, 

the FI sponsor umbrella allows the EPCS entity 58 to tailor \ t should be noted that the use of a security ticket enables, 

the list by FI sponsor. The banking entity 54 will additionally but does not mandate, a single sign-on procedure. In other 

process internal e-mail messages such as, for example, those words, a database entity such as, for example, the billing 

for sending data to other database entities, receiving data 40 entity 56 may, for whatever reason, require additional 

from other database entities, and broadcasting data to other authentication information. 

database entities. ^ £pcs eQtity sg ^ pTOces& mterna l messages 

Tlie billing entity 56 will process an internal message to relating t0 ag g r e ga tion data. For example, an EPCS entity 58 

add/update/delete/retrieve biller branding information, as ^ process an internal message t0 CTeate a link to summary 

well as an internal message to activate a subscriber for 45 or detailed bill information, or to create a link to message, 

electronic bill presentment via a messaging protocol, which noticef ad> or some other ^ of non . biU information that is 

can be an existing messaging protocol such as, for example, ava ilable from the billing entity 56. 

OFX or a batch process. The billing entity 56 will also ™ ms>o eo -n c .l • * 1 

; 4 »• !.„ •, «_.,•* j t The EPCS entity 58 will still further process an internal 

process an internal message to retrieve bill availability data, . / j * u-n ♦* u* ♦ c 

. • u-n a . 1 a . j u-n . • message to query /update bill payment transaction history for 

retneve bill detail data, and retrieve bill presentation speci- 50 f : 

fications or content. For example, the retrieved data could be P^ 0 ^ 01 customer care. 

URL links to ads and notices, HTML data, or OFX data. The ^ EPCS eDtit V 58 ^ additionally process internal 

hilling entity 56 will further process an internal message to e_mail messages such as, for example, those associated with 

query/update biller subscriber profile data for purposes of routing e-mail, picking-up e-mail, and querying and e-mail 

customer care. The billing entity 56 will still further process 55 ma ^ ox * 

an internal message to query biller transaction history for The EPCS entity 58 may also process internal messages 

customer care and for linking to the event tracking database. related to data mining. Such messages are handled very 

The billing entity 56 will additionally process internal e-mail carefully with respect to privacy, perhaps even providing an 

messages such as, for example, those for sending data to ACL or other mechanisms to ensure privacy. TTie results of 

other database entities, receiving data from other database eo such messages may be delivered out of band (e.g., by batch), 

entities, and broadcasting data to other database entities. As previously described, an external message interface 36 

The EPCS entity 58 will process internal event tracking defines messages that are used to communicate and query 

messages. Such event tracking messages are used to gain data between a given distributed database entity 30 and any 

access to two types of information in the event tracking existing system(s) that are directly related to the given 

database: summary data and a link to another database entry 65 distributed database entity 30. As also previously described, 

that can provide more detail. Such detail includes subscriber each external message interface 36 can be implemented 

enrollment data, subscriber service activation data (e.g., using any number of existing message -based communica- 
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tion systems, or with proprietary messaging software on a indirectly related systems are performed over interconnec- 

private network or intranet. Furthermore, the message speci- tions 98, which can be electrical wire, optical fiber, or 

fication or file format can be either standard (i.e., open) or microwave-based interconnections. 

proprietary. Depending upon the nature of the presentation technology 

Referring to FIG. 6, there is shown a schematic diagram 5 being used (e.g., a "fat" client, an HTML browser client, or 

of the versatile electronic bill presentment and payment a Java client), the user entity 52 may need to process a 

system 50, along with some associated directly related partner message in order to communicate with a partner such 

systems. The associated directly related systems comprise a as, for example, the personal finance system 90. The per- 

desktop database 80, a DDA system 82, a legacy billing sonal finance system 90 could be, for example, a personal 

system 84, and a legacy remittance system 86. The com- io financial manager (PFM) software package such as, for 

munications between the various database entities and their example, Quicken or Money. 

associated directly related systems are performed over inter- banking entity 54 will process partner messages to 

connections 88, which can be electrical wire, optical fiber, or and from a partner such as, for example, the banking system 

microwave-based interconnections. 92. 

Depending upon the nature of the presentation technology 35 ^ biUiDg erjtity 5$ ^ p rocess partner messages to and 

being used (e.g., a "fat" client, an HTML browser client, or fr om a partner such as, for example, the established billing 

a Java client), the user entity 52 may need to process an aggregator 94. Such a partner relationship may be required 

external message in order to communicate with an existing if a i arge 0 f subscribers are using the established 

system such as, for example, the desktop database 80. To hilling aggregator 94, and thereby have the leverage to 

support such a legacy system, it may be necessary to 20 demand that all of their bills come through the established 

implement the external message interface 36 of the user hilling aggregator 94. The established hilling aggregator 94 

entity 52 in the context of an existing, and possibly ^ essentially treated as a proxy for the billers that it 

extended, protocol specification, such as Gold, NPC, or represents. Thus, subscribers to the established billing 

OFX. aggregator 94 will have equal footing as subscribers to the 

The banking entity 54 will process external messages to present system 50. This means that subscribers to the 
and from an existing system such as, for example, the DDA established billing aggregator 94 will receive the same event 
system 82 in order to query and update information such as, tracking, customer service, and payment processing func- 
for example, subscriber profile data, subscriber account data, tionality as subscribers to present system 50. Of course, to 
out-of-band (e.g., ATM) account activity, and statement ^ gain the additional functionality provided by the present 
history. It's also conceivable that the banking entity 54 system 50, the established billing aggregator 94, or someone 
would need to interface with other banking systems (e.g., acting on their behalf, will need to provide the same pro- 
stops). Thus, the external message interface 36 of the gramming support that is required of any biller participating 
banking entity 54 is a key feature of the versatile electronic in the present system 50. 

bill presentment and payment system 50. 35 Xo present a bil j generated by the established billing 

The billing entity 56 will process external messages to aggregator 94, the present system 50 would, for example, 

and from an existing system such as, for example, the legacy receive bill availability data and the URL of a web server of 

billing system 84 in order to query and update information the established hilling aggregator 94, and the billing entity 

such as, for example, subscriber profile data, subscriber 56 would then point to the web server of the established 

account data, account activity, and statement history. Most 4Q billing aggregator 94 to get an HTML presentation of 

of this data is industry, if not biller, specific. Thus, the detailed bill data. In this scenario, the partner message 

external message interface 36 of the billing entity 56 is a key interface 38 would be essentially the same as an internal 

feature of the versatile electronic bill presentment and message interface 34, but possibly with added bulk transfer 

payment system 50. capability. 

The EPCS entity 58 will process external messages to and 45 The EPCS entity 58 will process partner messages to and 
from an existing system such as, for example, the legacy from a partner such as, for example, the alternative bill 
remittance system 86. The legacy remittance system 86 presentment and payment system 96. Such a partner re la- 
could be, for example, ACH, RPP, RPS, or Direct Send. tionship may be required if a billing entity 56 has a sub- 
As previously described, a partner message interface 38 scriber base that is split between using the present system 50 
defines messages that are used to communicate and query 50 and the alternative bill presentment and payment system 96. 
data between a given distributed database entity 30 and any In such a scenario, the present system 50 could function as 
existing system(s) that are indirectly related to the given a billing aggregator for the alternative bill presentment and 
distributed database entity 30. As also previously described, payment system 96, and vice-versa. However, the alternative 
each partner message interface 38 can be implemented using bill presentment and payment system 96 and its subscribers 
any number of existing message-based communication 55 would not receive any of the benefits of the messaging 
systems, or with proprietary messaging software on a private functionality provided by the present system 50. Only the 
network or intranet. Furthermore, the message specification minimum amount of functionality would be provided. That 
or file format can be either standard (i.e., open) or propri- is, the partner message interface 38 would only provide what 
etary. is required to present bills through the alternative bill 
Referring to FIG. 7, there is shown a schematic diagram 60 presentment and payment system 96, and not offer any of the 
of the versatile electronic bill presentment and payment advantages provided by the present system 50. The goal 
system 50, along with some associated indirectly related being to have the billing entity 56 encourage all of its 
systems. The associated indirectly related systems comprise subscribers to access bills through the present system 50. 
a personal finance system 90, a banking system 92, an It should be noted that the EPCS entity 58 will typically 
established billing aggregator 94, and an alternative bill 65 require the capabilities of a billing entity 56 in order to 
presentment and payment system 96. The communications present bills to and from the alternative bill presentment and 
between the various database entities and their associated payment system 96. 
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As previously described, a customer care message inter- customer service center 110, as shown in FIG. 9. In such an 
face 40 defines messages that are used to communicate and scenario, each of the database entities would process cus- 
query data between a given distributed database entity 30 tomer care messages to and from the centralized customer 
and a customer care entity. As also previously described, service center 110 similar to as described above. The corn- 
each customer care message interface 40 can be impie- 5 munications between the various database entities and the 
mented using any number of existing message-based com- centralized customer service center 110 would be performed 
munication systems, or with proprietary messaging software ove . r interconnections 112, which can be electrical wire, 
on a private network or intranet. Furthermore, the message °P tlcal fiber ' or microwave-based interconnections, 
specification or file format can be either standard (i.e., open) Referring to FIGS. 10-15, there are shown flowchart 
or proprietary 10 dia S rams °f data ^ message flows between the various 

entities within the system 50. These flowchart diagrams 



Referring to FIG. 8, there is shown a schematic diagram" 
of the versatile electronic bill presentment and payment 
system 50, along with some associated customer care enti- 
ties. The associated customer care entities comprise a us er 
entity self ; service centerJIOO. a banking entity customer 
service center 102, a billing entity customer service center 
104, and an EPCS customer service center 106. The com- 
munications between the various database entities and their 
associated customer care entities are performed over inter- 



assume that the user entity 52 is an HTML browser client, 
the banking entity 54 is the primary point of presence for a 
subscriber to the system 50, the billing entity 56 controls bill 
presentment, and the EPCS entity 58 controls bill payment. 
15 In FIG. 10, a subscriber at the user entity 52 accesses the 
web site of the banking entity 54 in step 200. In return, the 
banking entity 54 presents a branded interface to the user 
entity 52, including a sign-on request prompt in step 202. 
FIG. 16 shows an example of such a branded interface 120, 



connections 108, which can be electrical wire, optical fiber, ¥° wherein the sign-on request prompt includes a usemame 
or microwave-based interconnections. -J field 122 and a password field 124. 

Depending upon the nature of the presentation technology In FIG. 11, the user entity 52 submits a sign-on request 

being used (e.g., a "fat" client, an HTML browser client, or with authentication credentials in steps 204. The banking 

a Java client), the user entity 52 may need to process a entity 54 messages the EPCS entity 58 with the authentica- 

customer care message in order to communicate with a 25 tion credentials of the subscriber and the event is logged in 

customer care entity such as, for example, the user entity self step 206. The EPCS entity 58 provides a security ticket to 

service center 100. The user entity self service center 100 the banking entity 54 in step 208. The banking entity 54 

could be, for example, a self service diagnostic tool. delivers the security ticket to the user entity 52 and presents 

The banking entity 54 will process customer care mes- 3Q its "home page" to user entity 52 in step 210. FIG. 17 shows 

sages from a customer care entity such as, for example, the an example of such a home page 130, which includes a 

banking entity customer service center 102. A customer care "view bills" icon 132, a "view checking account" icon 134, 

message may be a request for data or a request to modify and a "view savings account" icon 136. 

existing data. The banking entity 54 will process such It should be noted that either the EPCS entity 58 or the 

customer care messages by providing the requested data or 35 banking entity 54 could perform the authentication 

providing a confirmation that the existing data has been procedure, but in either case the event is still logged in the 

modified, respectively, to the banking entity customer ser- event tracking database. 

vice center 102. The banking entity customer service center i n FIG. 12, the subscriber selects the "view bills" icon 132 

102 could be, for example, a third party telemarketing group in step 212. The banking entity 54 messages the EPCS entity 

that is allowed access to banking and overall system data in 4Q 58 with an aggregation data request and the event is logged 

order to provide feedback to system subscribers. i n step 214. The EPCS entity 58 presents aggregation data of 

The billing entity 56 will process customer care messages new bill availability to user entity 52 in step 216. FIG. 18 

from a customer care entity such as, for example, the billing shows a first modified home page 140 having an EPCS entity 

entity customer service center 104. A customer care message frame 142 presenting the new bill availability data, which 

may be a request for data or a request to modify existing 45 includes an "electric bill" icon 144, a "gas bill" icon 146, a 

data. The billing entity 56 will process such customer care "phone bill" icon 148, a "cable bill" icon 150, a "credit card 

messages by providing the requested data or providing a bill" icon 152, and an "all bills" icon 154 which allows all 

confirmation that the existing data has been modified, bills to be presented simultaneously, albeit in separate 

respectively, to the billing entity customer service center frames. 

104. The billing entity customer service center 104 could be, 50 In FIG. 13A, the subscriber selects the "gas bill" icon 146 

for example, a third party telemarketing group that is and is linked to the billing entity 56 along with the security 

allowed access to billing and overall system data in order to ticket in step 218. The billing entity 56 messages the EPCS 

provide feedback to system subscribers. entity 58 to log the "view bill" request event in step 220. The 

The EPCS entity 58 will process customer care messages billing entity 56 presents detailed bill data to the user entity 

from a customer care entity such as, for example, the EPCS 55 52 in step 222. FIG. 19 shows a second modified home page 

entity customer service center 106. A customer care message 160 having a billing entity frame 162 presenting the detailed 

may be a request for data or a request to modify existing bill data, which includes the subscriber name, subscriber 

data. The EPCS entity 58 will process such customer care address, account number, usage, and cost, and a "pay bill" 

messages by providing the requested data or providing a icon 164. 

confirmation that the existing data has been modified, 60 In FIG. 14, the subscriber selects the "pay bill" icon 164 

respectively, to the EPCS entity customer service center 106. and messages the EPCS entity 58 with a forward dated pay 

The EPCS entity customer service center 106 could be, for bill request so the event is logged in step 224. The EPCS 

example, a third party telemarketing group that is allowed entity 58 messages the billing entity 56 with a pay bill 

access to event and overall system data in order to provide request notification along with a bill identification number in 

feedback to system subscribers. $5 step 226. 

It should be noted that all of the customer care entities In FIG. 15, the EPCS posts a debit with the banking entity 

described above could be consolidated into a centralized 54 and the event is logged in step 228. The EPCS entity 58 
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then remits a payment to the billing entity 56 and the event 
is logged in step 230. 

FIG. 13B can be substituted for FIG. 13A in the above- 
described sequence of flowchart diagrams to show how 
detailed bill data can be provided by the established billing 
aggregator 94 thru the partner message interface 38 of the 
billing entity 56. In FIG. 13B, the subscriber again selects 
the "gas bill" icon 146 and is linked to the billing entity 56 
along with the security ticket in step 232. The billing entity 
56 again messages the EPCS entity 58 to log the "view bill" 
request event in step 234. However, in this case, detailed bill 
data is available only from the established billing aggregator 
94. Thus, the billing entity 56 accesses the established 
billing aggregator 94 through its partner message interface 
38 in step 236. In response, the established billing aggre- 
gator 94 provides detailed bill data to the billing entity 56 in 
step 238. The billing entity 56 then presents the detailed bill 
data to the user entity 52 in step 240. 

It should be noted that, in an alternative embodiment, the 
established billing aggregator 94 could present the detailed 
bill data directly to the user entity 52. 

FIG. 13C can be substituted for FIG. 13 A in the above- 
described sequence of flowchart diagrams to show how 
detailed bill data can be provided by the alternative bill 
presentment and payment system 96 thru the partner mes- 
sage interface 38 of the EPCS entity 58. In FIG. 13C, the 
subscriber selects the "gas bill" icon 146 and is linked back 
to the EPCS entity 58 along with the security ticket and the 
event is logged in step 242. In this case, detailed bill data is 
available only from the alternative bill presentment and 
payment system 96. Thus, the EPCS entity 58 accesses the 
alternative bill presentment and payment system 96 through 
its partner message interface 38 in step 244. In response, the 
alternative bill presentment and payment system 96 provides 
detailed bill data to the EPCS entity 58 in step 246. The 
EPCS entity 58 then presents the detailed bill data to the user 
entity 52 in step 248. 

It should be noted that, as previously described, the EPCS 
entity 58 will typically require the capabilities of a billing 
entity 56 in order to present bills to and from the alternative 
bill presentment and payment system 96. Alternatively, it 
should be noted that detailed bill data can be provided by the 
alternative bill presentment and payment system 96 thru the 
partner message interface 38 of the billing entity 56 in a 
manner similar to that as described in FIG. 13B. 

Referring to FIG. 20, there is shown a flowchart diagram 
of data and message flows between the centralized customer 
service center 110 and the various entities within the system 
50. A subscriber 170 contacts the centralized customer 
service center 110 regarding a bill payment in step 250. The 
centralized customer service center 110 accesses the event 
tracking database in the EPCS entity 58 to see if a view bill, 
pay bill, remit payment, or debit posting event has been 
logged in step 252. If more detailed information regarding, 
for example, the posting of a debit for a bill, the centralized 
customer service center 110 can access the database com- 
ponent 32 associated with the banking entity 54, as shown 
in step 254. Similarly, if more detailed information 
regarding, for example, the remitting of a payment for a bill, 
the centralized customer service center 110 can access the 
database component 32 associated with the billing entity 56, 
as shown in step 256. It should be noted that, although not 
shown, the EPCS entity 58 can log all of the above- 
described accesses performed by centralized customer ser- 
vice center 110. 

As is apparent from the foregoing description, the system 
50 allows a subscriber to interact directly with individual 
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billers while retaining the benefits of interacting with a 
single aggregator such as, for example, the ability to retain 
a single authentication and log-in procedure and a common 
bill presentation framework. The system 50 also allows a 
subscriber to retain the benefits of interacting with a single 
aggregator while allowing the billers and banks to retain 
certain preferences such as, for example, the ability to retain 
control of subscriber-related data and a communication 
channel with each subscriber. 

At this point it should be noted that while the foregoing 
detailed description was directed to an electronic bill pre- 
sentment and payment technique, any number of system 
types can employ the distributed database entities 30 to 
facilitate distributed data accessing within a network in 
accordance with the present invention. 

The present invention is not to be limited in scope by the 
specific embodiments described herein. Indeed, various 
modifications of the present invention in addition to those 
described herein, will be apparent to those of skill in the art 
from the foregoing description and accompanying drawings. 
Thus, such modifications are intended to fall within the 
scope of the appended claims. 

What is claimed is: 

1. A method for accessing data over a network having a 
plurality of network stations, the method comprising the 
steps of: 

storing, at a first of the plurality of network stations, 
information that identifies data which is available at a 
second of the plurality of network stations, the second 
network station being different than the first network 
station; 

generating, at the first network station, a signal represent- 
ing both the information that identifies the available 
data and linking information to the second network 
station; and 

transmitting the signal to a third of the plurality of 
network stations, the third network station being dif- 
ferent than the first and the second network stations; 

wherein the transmitted linking information is operable at 
the third network station to establish a network link 
over which the identified available data is transmittable 
from the second network station to the third network 
station. 

2. The method according to claim 1, further comprising 
the step of: 

receiving, at the first network station, a request for data 

from the third network station; 
wherein the signal is generated responsive to the receipt 

of the request. 

3. The method according to claim 2, wherein the request 
includes an identification of a user and further comprising 
the step of: 

authenticating the user; 

wherein the signal is generated after the user is authen- 
ticated. 

4. The method according to claim 2, further comprising 
the step of: 

logging the request. 

5. The method according to claim 1, further comprising 
the step of: 

storing the identified available data at the second network 
station. 

6. The method according to claim 1, further comprising 
the step of: 

receiving, at the first network station, a notification that 
the identified available data was transmitted from the 
second network station to the third network station. 
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7. The method according to claim 1, further comprising 
the step of: 

logging at least some events that occur within the net- 
work. 

8. The method according to claim 9, further comprising 
the step of: 

providing access to the logged events to an entity located 
outside of the network. 

9. The method according to claim 1, wherein the identified 
available data is transmittable from the second network 
station directly to the third network station over the network 
link. 

10. The method according to claim 1, wherein the iden- 
tified available data is transmittable from the second net- 
work station to the third network station so as to be dis- 
played in a presentation format. 

U. The method according to claim 10, wherein the 
presentation format is an internet web page. 

12. The method according to claim 10, wherein the 
presentation format is a frame of an internet web page. 

13. The method according to claim 1, further comprising 
the step of: 

providing the identified available data to the second 
network station. 

14. The method according to claim 13, wherein the 
identified available data is provided to the second network 
station by an entity located outside of the network. 

15. The method according to claim 1, wherein the iden- 
tified available data is identified available first data, wherein 
the linking information is first linking information, wherein 
the network link is a first network link, further comprising 
the step of: 

storing, at the first network station, further information 
that identifies second data which is available at a fourth 
of the plurality of network stations, the fourth network 
station being different than the first, the second, and the 
third stations; 

wherein the generated signal further represents both the 
further information that identifies the available second 
data and second linking information to the fourth 
network station; 

wherein the transmitted second linking information is 
operable at the third network station to establish a 
second network link over which the identified available 
second data is transmittable from the fourth network 
station to the third network station. 

16. The method according to claim 14, further comprising 
the step of: 

receiving, at the first network station, a request for data 

from the third network station, 
wherein the signal is generated responsive to the receipt 

of the request. 

17. The method according to claim 16, wherein the 
request includes an identification of a user and further 
comprising the step of: 

authenticating the user; 

wherein the signal is generated after the user is authen- 
ticated. 

18. The method according to claim 16, further comprising 
the step of: 

logging the request. 

19. The method according to claim 15, further comprising 
the step of: 

storing the identified available first data at the second 
network station; and 
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storing the identified available second data at the fourth 
network station. 

20. The method according to claim 15, further comprising 
the step of: 

5 receiving, at the first network station, a first notification 
that the identified available first data was transmitted 
from the second network station to the third network 
station; and 

receiving, at the first network station, a second notifica- 
10 tion that the identified available second data was trans- 
mitted from the fourth network station to the third 
network station. 

21. The method according to claim 15, further comprising 
the step of: 

15 logging at least some events that occur within the net- 
work. 

22. The method according to claim 21, further comprising 
the step of: 

providing access to the logged events to an entity located 
outside of the network. 

23. The method according to claim 15, wherein the 
identified available first data is transmittable from the sec- 
ond network station directly to the third network station over 
the first network link, and wherein the identified available 
second data is transmittable from the fourth network station 
directly to the third network station over the second network 
link. 

24. The method according to claim 15, wherein the 
identified available first data is transmittable from the sec- 
ond network station to the third network station so as to be 
displayed in a first presentation format, and wherein the 
identified available second data is transmittable from the 
fourth network station to the third network station so as to 
be displayed in a second presentation format. 

25. The method according to claim 24, wherein the first 
and the second presentation formats are internet web pages. 

26. The method according to claim 24, wherein the first 
and the second presentation formats are frames of an internet 
web page. 

27. The method according to claim 15, further comprising 
the steps of: 

providing the identified available first data to the second 

network station; and 
providing the identified available second data to the fourth 
network station. 

28. The method according to claim 27, wherein the 
identified available first data is provided to the second 
network station by a first entity located outside of the 
network, wherein the identified available second data is 
provided to the fourth network station by a second entity 
located outside of the network. 

29. A method for electronically presenting and paying 
bills in a network having a plurality of network stations, the 
method comprising the steps of: 

storing, at a first of the plurality of network stations, 
information identifying a bill which is available at a 
second of the plurality of network stations, the second 
network station being different than the first network 
60 station; 

receiving, from a third of the plurality of network stations, 
a request for the information identifying the available 
bill, the third network station being different than the 
first and the second network stations; 
65 authenticating the request from the third network station; 
generating, at the first network station, a signal represent- 
ing the information identifying the available bill and 
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linking information to the second network station, the 
linking information being operative at the third network 
station to establish a network link over which the 
identified available bill is transmittable from the second 
network station to the third network station; 

transmitting the signal to the third network station; 

receiving, at the first network station, a notification that 
the identified available bill was transmitted from the 
second network station to the third network station; and 

logging at least some of the aforementioned steps. 

30. An apparatus for accessing data over a network having 
a plurality of network stations, the apparatus comprising: 

a first storer for storing, at a first of the plurality of 
network stations, information identifying data which is 
available at a second of the plurality of network 
stations, the second network station being different than 
the first network station; 

a first generator for generating, at the first network station, 
a signal representing the information identifying the 
available data and linking information to the second 
network station; and 

a first transmitter for transmitting the signal to a third of 
the plurality of network stations, the third network 
station being different than the first and the second 
network stations; 

wherein the transmitted linking information is operable at 
the third network station to establish a network link 
over which the identified available data is transmittable 
from the second network station to the third network 
station. 

31. The apparatus according to claim 30, further com- 
prising: 

a receiver for receiving a request for data from the third 

network station; 
wherein the signal is generated responsive to the receipt 

of the request. 

32. The apparatus according to claim 31, wherein the 
request includes an identification of a user and further 
comprising: 

an authenticator for authenticating the user; 
wherein the signal is generated after the user is authen- 
ticated. 

33. The apparatus according to claim 31, further com- 
prising: 

a logger for logging the request. 

34. The apparatus according to claim 30, further com- 
prising: 

a second storer for storing the identified available data at 
the second network station. 

35. The apparatus according to claim 30, further com- 
prising: 

a receiver for receiving, at the first network station, a 
notification that the identified available data was trans- 
mitted from the second network station to the third 
network station. 

36. The apparatus according to claim 30, further com- 
prising: 

a logger for logging at least some events that occur within 
the network. 

37. The apparatus according to claim 36, further com- 
prising: 

a provider for providing access to the logged events to an 
entity located outside of the network. 

38. The apparatus according to claim 30, wherein the 
identified available data is transmittable from the second 
network station directly to the third network station over the 
network link. 
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39. The apparatus according to claim 30, wherein the 
identified available data is transmittable from the second 
network station to the third network station so as to be 
displayed in a presentation format. 

40. The apparatus according to claim 39, wherein the 
presentation format is an internet web page. 

41. The apparatus according to claim 39, wherein the 
presentation format is a frame of an internet web page. 

42. The apparatus according to claim 30, further com- 
prising: 

a provider for providing the identified available data to the 
second network station. 

43. The apparatus according to claim 42, wherein the 
identified available data is provided to the second network 
station by an entity located outside of the network. 

44. The apparatus according to claim 30, wherein the 
identified available data is identified available first data, 
wherein the linking information is first linking information, 
wherein the network link is a first network link, further 
comprising: 

a second storer for storing, at the first of the plurality of 
network stations, further information identifying sec- 
ond data which is available at a fourth of the plurality 
of network stations, the fourth network station being 
different than the first, the second, and the third network 
stations; 

wherein the generated signal further represents the further 
information identifying the available second data and 
second linking information to the fourth network sta- 
tion; 

wherein the transmitted second linking information is 
operable at the third network station to establish a 
second network link over which the identified available 
second data is transmittable from the fourth network 
station to the third network station. 

45. The apparatus according to claim 44, further com- 
prising: 

a receiver for receiving a request for data from the third 

network station; 
wherein the signal is generated responsive to the receipt 

of the request. 

46. The apparatus according to claim 45, wherein the 
request includes an identification of a user and further 
comprising: 

an authenticator for authenticating the user; 
wherein the signal is generated after the user is authen- 
ticated. 

47. The apparatus according to claim 45, further com- 
prising: 

a logger for logging the request. 

48. The apparatus according to claim 44, further com- 
prising: 

a third storer for storing the identified available first data 

at the second network station; and 
a fourth storer for storing the identified available second 

data at the fourth network station. 

49. The apparatus according to claim 44, further com- 
prising: 

a first receiver for receiving, at the first network station, 
a first notification that the identified available first data 
was transmitted from the second network station to the 
third network station; and 

a second receiver for receiving, at the first network 
station, a second notification that the identified avail- 
able second data was transmitted from the fourth net- 
work station to the third network station. 



03/12/2004, EAST Version: 1.4.1 



6,055,567 

23 24 

50. The apparatus according to claim 44, further com- was transmitted from the second network station to the 
prising: third network station; and 

a logger for logging at least some events that occur within a logger for logging at least some of the aforementioned 

the network. steps. 

51. The apparatus according to claim 50, further com- 5 59. An article of manufacture for accessing data over a 
prising: network having a plurality of network stations, the article of 

a provider for providing access to the logged events to an manufacture comprising: 

entity located outside of the network. a computer readable storage medium; and 

52. The apparatus according to claim 44, wherein the computer programming stored on the storage medium; 
identified available first data is transmittable from the sec- 10 wherein the stored computer programming is config- 
ond network station directly to the third network station over ured to be readable from the computer readable storage 
the first network link, and wherein the identified available medium by at least one computer and thereby cause the 
second data is transmittable from the fourth network station at least one computer to operate so as to: 

directly to the third network station over the second network store, at a first of the plurality of network stations, 

link. 15 information that identifies data which is available at 

53. The apparatus according to claim 44, wherein the a second of the plurality of network stations, the 
identified available first data is transmittable from the sec- second network station being different than the first 
ond network station to the third network station so as to be network station; 

displayed in a first presentation format, and wherein the generate, at the first network station, a signal repre- 
identified available second data is transmittable from the 20 senting both the information that identifies the avail- 
fourth network station to the third network station so as to able data and linking information to the second 
be displayed in a second presentation format. network station; and 

54. The apparatus according to claim 53, wherein the first transmit the signal to a third of the plurality of network 
and the second presentation formats are internet web pages. stations, the third network station being different 

55. The apparatus according to claim 53, wherein the first 25 than the first and the second network stations; 

and the second presentation formats are frames of an internet wherein the transmitted linking information is operable 

web page. at the third network station to establish a network 

56. The apparatus according to claim 44, further com- link over which the identified available data is trans- 
prising: mittable from the second network station to the third 

a first provider for providing the identified available first 30 network station. 

data to the second network station; and 60 - T** article of manufacture according to claim 59, 

a second provider for providing the identified available farthcr causin 8 me at least one computer to operate so as to: 

second data to the fourth network station. receive a request for data from the third network station; 

57. The apparatus according to claim 56, wherein the wherein the signal is generated responsive to the receipt 
identified available first data is provided to the second 35 of the request. 

network station by a first entity located outside of the 61. The article of manufacture according to claim 60, 

network, wherein the identified available second data is wherein the request includes an identification of a user, and 

provided to the fourth network station by a second entity further causing the at least one computer to operate so as to: 

located outside of the network. authenticate the user; 

58. An apparatus for electronically presenting and paying 40 wherein the signal is generated after the user is authen- 
bills in a network having a plurality of network stations, the ticated. 

apparatus comprising: 62. The article of manufacture according to claim 60, 

a storer for storing, at a first of the plurality of network further causing the at least one computer to operate so as to: 

stations, information identifying a bill which is avail- ^ log the request. 

able at a second of the plurality of network stations, the 63. The article of manufacture according to claim 59, 

second network station being different than the first further causing the at least one computer to operate so as to: 

network station; store the identified available data at the second network 

a first receiver for receiving, from a third of the plurality station, 

of network stations, a request for the information 5Q 64. The article of manufacture according to claim 59, 

identifying the available bill, the third network station further causing the at least one computer to operate so as to: 

being different than the first and the second network receive, at the first network station, a notification that the 

stations; identified available data was transmitted from the sec- 

an authenticator for authenticating the request from the ond network station to the third network station, 

third network station; 55 65. The article of manufacture according to claim 59, 

a generator for generating, at the first network station, a further causing the at least one computer to operate so as to: 

signal representing the information identifying the log at least some events that occur within the network, 

available bill and linking information to the second 66. The article of manufacture according to claim 65, 

network station, the linking information being opera- further causing the at least one computer to operate so as to: 

tive at the third network station to establish a network 60 provide access to the logged events to an entity located 

link over which the identified available bill is trans- outside of the network. 

mittable from the second network station to the third 57. The article of manufacture according to claim 59, 

network station; wherein the identified available data is transmittable from 

a transmitter for transmitting the signal to the third the second network station directly to the third network 

network station; 65 station over the network link, 

a second receiver for receiving, at the first network 68. The article of manufacture according to claim 59, 

station, a notification that the identified available bill wherein the identified available data is transmittable from 
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the second network station to the third network station so as 
to be displayed in a presentation format. 

69. The article of manufacture according to claim 68, 
wherein the presentation format is an internet web page. 

70. The article of manufacture according to claim 68, 
wherein the presentation format is a frame of an internet web 
page. 

71. The article of manufacture according to claim 59, 
further causing the at least one computer to operate so as to: 

provide the identified available data to the second network 
station. 

72. The article of manufacture according to claim 71, 
wherein the identified available data is provided to the 
second network station by an entity located outside of the 
network, 

73. The article of manufacture according to claim 59, 
wherein the identified available data is identified available 
first data, wherein the linking information is first linking 
information, wherein the network link is a first network link, 
further causing the at least one computer to operate so as to: 

store, at the first of the plurality of network stations, 
further information that identifies second data which is 
available at a fourth of the plurality of network stations, 
the fourth network station being different than the first, 
the second, and the third network stations; 

wherein the generated signal further represents the further 25 
information that identifies both the available second 
data and second linking information to the fourth 
network station; 

wherein the transmitted second linking information is 
operable at the third network station to establish a 30 
second network link over which the identified available 
second data is transmittable from the fourth network 
station to the third network station. 

74. The article of manufacture according to claim 73, 
further causing the at least one computer to operate so as to: 

receive a request for data from the third network station; 
wherein the signal is generated responsive to the receipt 
of the request. 

75. The article of manufacture according to claim 74, 
wherein the request includes an identification of a user and 
further causing the at least one computer to operate so as to: 

authenticate the user; 

wherein the signal is generated after the user is authen- 
ticated. 

76. The article of manufacture according to claim 74, 
further causing the at least one computer to operate so as to: 

log the request. 

77. The article of manufacture according to claim 73, 
further causing the at least one computer to operate so as to: 

store the identified available first data at the second 

network station; and 
store the identified available second data at the fourth 

network station. 

78. The article of manufacture according to claim 73, 
further causing the at least one computer to operate so as to: 

receive, at the first network station, a first notification that 
the identified available first data was transmitted from 
the second network station to the third network station; 
and 

receive, at the first network station, a second notification 
that the identified available second data was transmitted 
from the fourth network station to the third network 
station. 

79. Hie article of manufacture according to claim 73, 
further causing the at least one computer to operate so as to: 

log at least some events that occur within the network. 

80. The article of manufacture according to claim 79, 
further causing the at least one computer to operate so as to: 



provide access to the logged events to an entity located 
outside of the network. 

81. The article of manufacture according to claim 73, 
wherein the identified available first data is transmittable 
from the second network station directly to the third network 
station over the first network link, and wherein the identified 
available second data is transmittable from the fourth net- 
work station directly to the third network station over the 
second network link. 

82. The article of manufacture according to claim 73, 
wherein the identified available first data is transmittable 
from the second network station to the third network station 
so as to be displayed in a first presentation format, and 
wherein the identified available second data is transmittable 
from the fourth network station to the third network station 

15 so as to be displayed in a second presentation format. 

83. The article of manufacture according to claim 82, 
wherein the first and the second presentation formats are 
internet web pages. 

84. The article of manufacture according to claim 82, 
wherein the first and the second presentation formats are 
frames of an internet web page. 

85. The article of manufacture according to claim 73, 
further causing the at least one computer to operate so as to: 

provide the identified available first data to the second 

network station; and 
provide the identified available second data to the fourth 
network station. 

86. The article of manufacture according to claim 85, 
wherein the identified available first data is provided to the 
second network station by a first entity located outside of the 
network, wherein the identified available second data is 
provided to the fourth network station by a second entity 
located outside of the network. 

87. An article of manufacture for electronically presenting 
and paying bills in a network having a plurality of network 
stations, the article of manufacture comprising the steps of: 

a computer readable storage medium; and 
computer programming stored on the storage medium; 
wherein the stored computer programming is config- 
ured to be readable from the computer readable storage 
medium by at least one computer and thereby cause the 
at least one computer to operate so as to: 
store, at a first of the plurality of network stations, 
information identifying a bill which is available at a 
second of the plurality of network stations, the 
second network station being different than the first 
network station; 
receive, from a third of the plurality of network 
stations, a request for the information identifying the 
available bill, the third network station being differ- 
ent than the first and the second network stations; 
authenticate the request from the third network station; 
generate, at the first network station, a signal repre- 
senting the information identifying the available bill 
and linking information to the second network 
station, the linking information being operative at the 
third network station to establish a network link over 
which the identified available bill is transmittable 
from the second network station to the third network 
station; 

transmit the signal to the third network station; 
receive, at the first network station, a notification that 
the identified available bill was transmitted from the 
second network station to the third network station; 
and 

log at least some of the aforementioned steps. 
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